Subject: [saag] software update for teeny-weeny devices (was: Fwd: [Iotsu] Initial version of the IoTSU workshop report submitted)

From: Stephen Farrell <[email-masked]>
Date: Fri, 7 Oct 2016 20:47:30 +0100

Hiya,

I hope this is of interest to some folks here. If so, please
join the [email-masked] list and/or discuss here.

Do folks think this'd be a good topic on which to spend some
time at the saag session at IETF97?

Cheers,
S.

-------- Forwarded Message --------
Subject: [Iotsu] Initial version of the IoTSU workshop report submitted
Date: Fri, 7 Oct 2016 19:44:03 +0000
From: Hannes Tschofenig <[email-masked]>
To: [email-masked] <[email-masked]>

Hi all,

I have just submitted the initial version of the report:
https://tools.ietf.org/html/draft-farrell-iotsu-workshop-00

We tried to capture the received comments as best as we could but I am
sure there is room for improvement.
Feedback is welcome!

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy
the information in any medium. Thank you.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 9 Oct 2016 02:22:19 +0000

Stephen Farrell <[email-masked]> writes:

Just had a quick skim through this (I've printed it out for later reading when
I've got more time), but wanted to post my immediate response to one of the
points I saw:

>There was a bit of discussion about the importance for IoT devices to know
>the current time for the purpose of checking certificate validity.

"And now you have two problems...".

It'd also be good to have a problem statement of some kind rather than just a
shopping list of stuff, or some indication of where the authors are coming
from when they create their list.  I've never seen an IoT device that can
handle differential updates, has dynamic linking (or dynamic anything, there's
usually just a single system image), and a whole pile of other stuff discussed
here.  Is this just gedanken-experimenting or are there real devices being
considered?  It looks like a lot of the issues being raised simply don't apply
to most IoT devices...

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 9 Oct 2016 18:59:24 +0100

Hi Peter,

On 09/10/16 03:22, Peter Gutmann wrote:
> from when they create their list.  

The authors of the draft are just trying to reflect what
happened at the workshop (as it says in the draft).

> I've never seen an IoT device that can

A lot of course depends on what devices one associates with
the marketing-term IoT. One of the companies who attended
the workshop (electric imp) do updates that were more
complex than I had thought were done but iirc the complex
update schemes only or mostly applied to bigger devices.
I forget if they claimed differential updates or not. I
do recall that a colleague of mine who does s/w engineering
research was interested in research in that space.

If the text of the draft gives the wrong impression about
any of that, I'd appreciate pointers to help us fix it.

And of course, I'd be even more interested if there are
bits of work that could help improve the likelihood that
small devices get updated. And, on this list, most especially
if there's stuff it'd be worth doing in the IETF. (Personally
I think there are things the IETF could do to help, but I'm
not sure if the bits of work the IETF could do would really
see deployment and there's no point doing paperwork for
fun.)

S.

---

From: David Woodhouse <[email-masked]>
Date: Sun, 09 Oct 2016 20:02:16 +0100

> "And now you have two problems...".

Right. I believe UEFI firmware deliberately *avoids* the time checking,
because it is known that even when battery-backed RTC hardware *does*
exist, as it does in a PC, you can't rely on it being set to the
correct time.

I understand that a lot of IoT devices are specifically designed to be
unreliable — requiring Internet connectivity instead of being operable
purely over a local network. But requiring the correct time would just
be a step too far, surely?

-- 
dwmw2

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 Oct 2016 10:41:14 +0200

Hi Peter,

> considered?  It looks like a lot of the issues being raised simply don't apply

We tried to derive a list of features everyone agreed to but that wasn't
as easy as you might think.

I have been talking to companies who had implemented and deployed
differential updates for IoT devices. I agree that dynamic linking is
less common in IoT devices but there are OSs that support this type of
functionality. Many systems are indeed only shipping entire firmware
images and reboot the device afterwards. This is easier to implement and
works in most cases just fine. Of course, with many IoT devices
companies are re-writing everything from scratch and while they may have
great plans at the start of the project they may find out (after some
time) that all implementing all these features (particularly the
security stuff) takes some time.

Ciao
Hannes

Ciao
Hannes

> 
> Peter.
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 Oct 2016 10:44:40 +0200

Hi David,

> be a step too far, surely?

Of course there is a certain cost associated with adding a real-time
clock and to also configure it with the correct time. Our story for
providing time securely to these device isn't that great either since
NTP again assumes that you have been configured with the correct time.

I believe that while companies make use of certificates for reasons of
familiarity with the tools and the technology they are actually just
using the SubjectPublicKeyInfo part of it.

Ciao
Hannes

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 11 Oct 2016 03:48:22 +0000

Stephen Farrell <[email-masked]> writes:
>>It'd also be good to have a problem statement of some kind rather than just
>>a shopping list of stuff, or some indication of where the authors are coming
>The authors of the draft are just trying to reflect what happened at the
>workshop (as it says in the draft).

So were there no requirements given at the workshop, no use cases?  At the
moment it feels like being told the punchline of a joke, "And then the farmer
said 'You'll have to take the sheep as well'" [0], but without the setup you
can't tell what's going on.

>If the text of the draft gives the wrong impression about any of that, I'd
>appreciate pointers to help us fix it.

It's not really the wrong impression, it's a very incomplete impression.  It's
like a bunch of people got together and came up with a list of problems,
without really specifying what it was they were trying to do.  I know in
general what's being discussed, but without any requirements or use cases I
can just make a whole pile of the problems discussed go away by saying "well
don't do that, then", the prime example being the one I pointed out, if you
ignore certificates, or throw away CRLs and use something more functional,
then you don't have to worry about having a RTC.

Peter.

[0] Obviously this is an Australian joke.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 11 Oct 2016 03:56:26 +0000

David Woodhouse <[email-masked]> writes:

>unreliable — requiring Internet connectivity instead of being operable purely
>over a local network. But requiring the correct time would just be a step too
>far, surely?

You don't even need it, it's an artefact of someone's decision to use
certificates because... well who knows, since there's no rationale or
requirements.  In fact the doc doesn't even say what needs to be checked for
revocation, a code-signing cert, device certs, what?  It's just "certs will be
used and therefore we need revocation".

Actually now you have at least three problems, not just two.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 11 Oct 2016 04:05:40 +0000

Hannes Tschofenig <[email-masked]> writes:

>familiarity with the tools and the technology they are actually just using
>the SubjectPublicKeyInfo part of it.

Yeah, that's quite widespread in SCADA/embedded, you parse through to the SPKI
and pull out the public key and throw the rest away (my code has a build
option USE_PSEUDOCERTIFICATES for just this use case, you get a pointer to a
fixed pre-encoded cert in flash and a public-key object in RAM, saving
100-200kB of code space and tens of kB of RAM).  Mind you that does
immediately lead to the follow-up question, why worry about revocation issues
when the device isn't even looking at the cert?

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Oct 2016 12:43:35 +0100

On 11/10/16 04:48, Peter Gutmann wrote:
> So were there no requirements given at the workshop, no use cases? 

The workshop did not produce the one true list of requirements
nor use-cases, no. And nor should it have attempted to do that
IMO.

> At the
> without really specifying what it was they were trying to do. 

Is there a clue in the fact that it was called a workshop? ;-)

> I know in

If you read the text of the report as being a recommendation
for strict adherence to x.509 or rfc5280+revocation-checking
then we should fix it so it doesn't read that way. But I don't
think it does read that way, and it's certainly not intended
to be written that way, at least by me. Again, if you can
point out text that lead you to think that that'd be great and
we can fix it. (That's fine offlist if that's easier.)

Cheers,
S.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 12 Oct 2016 03:48:46 +0000

Stephen Farrell <[email-masked]> writes:

>If you read the text of the report as being a recommendation for strict 
>adherence to x.509 or rfc5280+revocation-checking then we should fix it so 
>it doesn't read that way. 

Well, in the absence of any requirements I had to kind of reverse-engineer 
what the report was trying to do from the text, like reverse-engineering a
joke from its punchline.  Since it mentioned certs I assumed they were
required, but without anything indicating what's meant to be achieved I guess 
any statement in the report could be right, wrong, or both at the same time.
It's really hard to tell (insert Bob Morris (?) quote about "the behaviour
of a program without a specification can never be wrong, only surprising").

Peter.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Oct 2016 07:42:36 +0100

Peter,

> of a program without a specification can never be wrong, only surprising").

I think we're done here. Given that the abstract says:

   This document provides a summary of the 'Workshop on Internet of
   Things (IoT) Software Update (IOTSU)' which took place at Trinity
   College Dublin, Ireland on the 13th and 14th of June, 2016.  The main
   goal of the workshop was to foster a discussion on requirements,
   challenges and solutions for bringing software and firmware updates
   to IoT devices.  This report summarizes the discussions and lists
   recommendations to the standards community.

I have no clue how the document could be clearer as to its
purpose, nor how you seem to confuse "foster a discussion of
requirements" with some idea that the draft should set out
a consensus-based list of requirements for the one true way
to do s/w update.

My conclusion so far is that in this case you prefer to carp
about x.509 rather than be constructive, which is fine given
the imperfection of x.509 but a) shooting those fish in that
barrel has been done, and b) suggests that this thread had
outlived it's usefulness even before being started.

If you or anyone else who has read the draft finds it similarly
confusing and is willing to actually point at text that confused
them, then I'd still be happy to improve the text.

If someone (you included) wants to suggest text along the lines
of "here are a few of the many reasons strict adherence to x.509
wouldn't be a good plan for s/w update in this case ..." then
that'd be fine too. (But better done on the iotsu list and not
this one probably.)

S.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 13 Oct 2016 05:48:47 +0000

Stephen Farrell <[email-masked]> writes:

>I think we're done here.

You asked for feedback on the doc, I thought I'd have a look and try and
provide some but since there were no requirements I wasn't able to evaluate
the doc against anything to see if there were problems.  You've indicated that
there are no requirements, in which case I guess we are done, I can't provide
useful feedback on something for which the requirements are a null set.

The X.509 stuff was just the first thing that leaped out at me, there's no
particular significance attached to it.

Peter.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 13 Oct 2016 10:01:42 +0100

On 10 October 2016 at 09:44, Hannes Tschofenig
<[email-masked]> wrote:
> Our story for

How so?

BTW, are you aware of roughtime? https://roughtime.googlesource.com/roughtime

---

From: Mohit Sethi <[email-masked]>
Date: Sun, 16 Oct 2016 11:02:10 -0400

Dear all

I find this draft useful for what it is: a summary of the discussions 
from the software update workshop.

I have two minor comments. I hope they can be addressed in the future 
versions:

1. For me scheduling of updates is important: I don't want my connected 
light bulb to update at night when I am using it. Although software 
updates should be as automated as possible, complete automation can lead 
to havoc. Continuing on the light example, I may want to only update the 
light bulbs in one room and see the consequences before updating the 
light bulbs in my entire house. How to encourage/force users to perform 
critical updates is still an important concern. The draft does touch 
upon this but never states this explicitly as a requirement. I am hoping 
that this can be addressed somewhere in the draft?

2. The draft provides a lot of useful examples. For example, I found it 
useful to read the story about Little Printer and how its code was 
released as open source. I am hoping that the draft could try to 
document more examples. There are other open source projects that have 
been picked up by the community such openwrt and cyanogenmod. Similarly, 
while the eyefi example is useful, perhaps it would nice to document the 
case of Revolv smart hub which is no longer supported. I don't think 
documenting all the examples out there is necessary, but providing many 
references and examples would definitely help.

Thanks
/--Mohit

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 18 Oct 2016 00:07:18 +0000

Mohit Sethi <[email-masked]> writes:
 
>For me scheduling of updates is important: I don't want my connected light
>bulb to update at night when I am using it.

So not this then:

https://twitter.com/markrittman/status/785905327967498240/photo/1

(that was part of an 11-hour battle to get a WiFi kettle working).

Peter.

---

From: Mohit Sethi <[email-masked]>
Date: Tue, 18 Oct 2016 15:52:01 -0400

Thanks for the pointer. This was indeed hilarious and sad to follow on 
Twitter. I think it highlights another important problem of 
bootstrapping/configuring IoT devices. At some point Mark has to run a 
port scanner to find out what IP address was assigned to his WiFi Kettle.

But for his light bulb not working during dinner time, at least in this 
case I think he manually confirmed the firmware update. Perhaps the user 
can be better informed in future that the installing firmware updates 
may make the light bulb unusable for x amount of time.

Thanks
/--Mohit