Subject: Re: [homenet] write up of time without clocks

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 01 Nov 2016 13:50:43 +0100

> But, we talked about how this wasn't a totally catch-22, that we could
> know how it was "at least" some time based upon file timestamp, or
> self-certificate not-before dates, or do DNSSEC without time validation
> first.

> My question is: did this get captured into document somewhere?

In case you decide to write something up, here's what I know about
filesystem timestamps:

  - the Raspberry Pi uses a filesystem timestamp maintained by Debian's
    "fake-hwclock";
  - on OpenWRT/LEDE, something much more naive happens in 
    /etc/init.d/sysfixtime.

Now filesystem timestamps are good enough to make sure file modtimes are
monotonic, so that tools such as e.g. make don't break; however, they
might not be good enough for crypto, since a filesystem might not be
updated for months or years (think of a device that's been kept powered
off for a year or two and suddenly needs to bootstrap its DNSSec stub
resolver).  I think that designing protocols so that they can bootstrap
with time that is years in the past is absolutely necessary -- there's
just no way around it.  Working around protocol deficiencies with tricks
like roughtime will lead to brittle networks.

To my untrained eyes, the issue is similar to that of seeding the system
RNG for crypto purposes.  It is my impression that this particular issue
is mostly solved:

  - some SoCs have a hardware RNG (e.g. TI Sitara);
  - the ath9k WiFi driver produces system randomness from radio noise;
  - havege[1] works fine on systems that don't do it in hardware;
  - some systems save a blob of random data on shutdown, and hash it back
    at startup (Debian does it in /etc/init.d/urandom).

I'll be happy to review anything you write on the subject.

-- Juliusz

---

From: Philip Homburg <[email-masked]>
Date: Tue, 01 Nov 2016 15:52:48 +0100

>like roughtime will lead to brittle networks.

Today, basically the only way to get reliable time is to set up a TLS
connection to a trusted server that gives the device some idea about time.

If the device is always on, then regularly writing timestamps to local
storage is good, but only if ntp cannot step the time backwards.

Assuming just plain ntp without any kind of authentication, then it doesn't
make much sense to do local DNSSEC valition just to get the address of some
ntp server.

Note that there will be a KSK roll-over for the root zone next year. So any
device that wakes up two years from now probably doesn't have valid trust 
material for DNS anyhow.

Which brings me to the following: given that all code has security issues,
maybe devices should check for updates and just shutdown if they can't
verify that they are running the latest firmware?

So the device should have the vendor's long term TLS certicate. With possibly
an option for the user to disable this kind of security if the device is
not actually connected to the internet.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Nov 2016 08:38:04 +1300

On 02/11/2016 03:52, Philip Homburg wrote:
...
> verify that they are running the latest firmware?

That sounds absolutely dreadful for disaster recovery scenarios where
the Internet is badly broken (after a hurricane, earthquake, etc.)
and people need to restart essential systems (or they need to restart
themselves).

> not actually connected to the internet.

No, during disaster recovery the last thing you need is for ordinary people
to be faced with strange security alerts that they've never seen before.
(It's rather like advising people to go into the BIOS to change an option
while the fire alarm is ringing.)

Things need to just work during disaster recovery.

    Brian

---

From: Philip Homburg <[email-masked]>
Date: Wed, 02 Nov 2016 11:29:27 +0100

>Things need to just work during disaster recovery.

Maybe I live in an unusual part of the world. But this seems very far fetched
to me for two different reasons:

- I rate the risk of ddos attack like against Dyn way higher than a large
  physical disaster. Though I have to admit that there are parts of the
  world where the risk of disaster is a lot larger than here. Of course,
  building code also very from country to country taking into account
  disasters that may take place.

- The bigger issue is that I can easily imagine partial internet access,
  but that is mostly unrelated to physical disasters. I'm really curious
  how you think a disaster leaves the internet broken enough that CPEs
  can't phone home, but working well enough that people in the middle of
  can communicate with each other.

That said, if you think that there is a strong need for CPEs to continue to
work in a badly damaged internet, then it makes sense to make that an official
requirement. If requires specifying what this badly damaged internet really
looks like and how to test if devices can cope.

Otherwise, CPE vendors may just silently implement what I suggest and we will
only find out during a disaster where things don't work.

---

From: Teco Boot <[email-masked]>
Date: Wed, 2 Nov 2016 19:54:50 +0100

> Op 2 nov. 2016, om 11:29 heeft Philip Homburg <[email-masked]> het volgende geschreven:
> 

This is about "not actually connected to the internet". Could be "a large 
physical disaster", a "ddos attack like against Dyn" or whatever connection
failure.

So +1 for "Things need to just work during disaster recovery".

This started with a need for somewhat accurate system time for certificate 
validation, right? I have to deal with stuff lacking a RTC battery. I save 
system time every now and then in flash. During startup, clock jumps forward
to RTC when warm start occurs (main power was not interrupted) or to saved 
system time when a cold boot occurs. When clock is behind, it jumps forwards 
when NTP syncs. My certificates do not expire during "powered off, on the 
shelf".

Teco

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Nov 2016 09:12:32 +1300

>   disasters that may take place.

It's not an easy trade-off, agreed.

>   can communicate with each other.

If you live (as I do) on a large island in an earthquake prone region, a
disaster that would cut all international Internet links for weeks is far
from impossible, and the vendor servers are all overseas.

> only find out during a disaster where things don't work.

The risk I see is that if a message comes up that says "Cannot contact vendor
server: override security check?" the user will always click "yes". So in fact
this check will be a no-op and also become an attack target in itself.

I have no pixie dust to fix this.

    Brian

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 03 Nov 2016 00:10:38 +0100

>> ddos attack like against Dyn

I could be wrong, but I believe that Dyn was DDoSed by the Mirai botnet,
which propagates by exploiting devices configured with default credentials.
This has nothing to do with outdated firmwares.

-- Juliusz

---

From: Philip Homburg <[email-masked]>
Date: Thu, 03 Nov 2016 12:23:37 +0100

> This started with a need for somewhat accurate system time for
> certificate validation, right? I have to deal with stuff lacking
> a RTC battery. I save system time every now and then in flash.
> During startup, clock jumps forward to RTC when warm start occurs
> (main power was not interrupted) or to saved system time when a
> cold boot occurs. When clock is behind, it jumps forwards when NTP
> syncs. My certificates do not expire during "powered off, on the
> shelf".

The problem is that security protocols like TLS and DNSSEC rely on 
secure, accurate time without specifying how to get that. At the moment
we don't have any way to distributee secure accurate time of a large scale.

Without accurate time you have too fool around to make it work. And without
a serious security analysis, you will only find out what it means to rely
on a best effort time service when the security of your system is broken
(or a security researcher gives a nice presentation on a security conference).

Note that just saving the time to flahs is very likely to break DNSSEC. Many
zones have very short lifetimes (in the order of weeks). So if the device
is off for a couple of weeks, the local time will be before the start time
of the signature and DNSSEC validation will fail.

My guess is that as letsencrypt is becoming more wide spread, having a clock
off by a couple of months will also cause issues there.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 03 Nov 2016 12:32:53 +0100

>This has nothing to do with outdated firmwares.

The problem is that you cannot realistically update those firmwares.

If is trivial to compile a new firmware for those devices that doesn't 
request upnp to open ports to telnet or ssh. But is is impossible to deploy
such an update.

For consumer electronics, we cannot rely on consumers to actually download and
install new firmware. So part of the solution to securing those devices
has to be that (out of the box) they will update automatically.

For the same reason, having lots of devices on the internet that have been
abandoned by the vendor is also a huge security risk. So ideally those devices
should shutdown automatically.

Note that PCs, browsers, etc. are now somewhat secure because they update
automatically. We need to do the same will all other devices connected to
the internet.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 3 Nov 2016 15:00:15 +0000

> >I could be wrong, but I believe that Dyn was DDoSed by the Mirai
> >botnet, which propagates by exploiting devices configured with default
> credentials.

Many companies provide devices that do automated updates. It's totally realistic to update firmwares. There exist various methods, tools and best practices. The problem is that some manufacturers don't bother to make their devices upgradable. By not having to maintain the firmware of shipped devices, the devices can be sold very inexpensively. So price-conscious consumers will  buy them, instead of the more expensive, well-maintained devices. 

> It is trivial to compile a new firmware for those devices that doesn't request
> upnp to open ports to telnet or ssh. But is is impossible to deploy such an
> update.

I can't speak for others, but DIRECTV set-top-boxes all do auto update, as do Digital Life IoT devices, and U-verse residential gateways. I think iControl IoT devices do, too. So, no, it's not impossible. It's just cheaper and requires less skill and effort to create devices that can't be updated. The exploited vulnerabilities (in the Dyn attack) have been known for years, and fixes have been available for years. Even after they were known, new units were still shipping with the vulnerability. Secure methods for updating devices and best practices for using these methods have existed for years. If the device manufacturer had built in a mechanism to allow for secure, automated updates (and not hard-coded a default password for access to all devices that couldn't even be changed by firmware update), and had made updates available in a timely manner, there wouldn't have been vast numbers of devices to exploit. 

> For consumer electronics, we cannot rely on consumers to actually download
> and install new firmware. So part of the solution to securing those devices

+1
 
> should shutdown automatically.

Which means the vendor would still be responsible for building in a remote "kill switch". Ideally, manufacturers would be required to warn consumers prior to purchase that the device will be bricked (or maybe just have all IP connectivity disabled) if it is ever discovered to have an easily exploitable vulnerability.
 
> Note that PCs, browsers, etc. are now somewhat secure because they
> update automatically. We need to do the same with all other devices
> connected to the internet.

+1

Barbara

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 03 Nov 2016 19:48:08 +0100

> The problem is that you cannot realistically update those firmwares.

Philip -- please read my mail again.  The Dyn attack has nothing to do
with out-of-date firmwares.

I cannot stress this enough: out-of-date firmwares are the least of our
problems at this stage.  We're being attacked by devices that ship with
a well-known default password, and in some cases by devices that ship with
a well-known backdoor that's impossible to disable:

  https://mjg59.dreamwidth.org/40397.html

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Nov 2016 08:26:12 +1300

Barbara,

On 04/11/2016 04:00, STARK, BARBARA H wrote:
> Many companies provide devices that do automated updates. It's totally realistic to update firmwares.

Not always. My CE can't be updated any more, I think because its flash memory is too small
for recent versions. And I had the same experience a few years ago with a previous CE. Not to
mention that most vendors simply stop supporting old hardware after a few years. Also
as Juliusz pointed out, if the device was shipped with user admin, password admin and the
user (being a normal citizen) doesn't change it, any amount of new vendor firmware won't
fix it.

Yes, I agree it's possible to do better, but what's the incentive for a bottom-feeding vendor
of cheap devices to bother?

Regards
    Brian

> There exist various methods, tools and best practices. The problem is that some manufacturers don't bother to make their
devices upgradable. By not having to maintain the firmware of shipped devices, the devices can be sold very inexpensively. So
price-conscious consumers will  buy them, instead of the more expensive, well-maintained devices.

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 3 Nov 2016 21:48:36 +0200

> of cheap devices to bother?

I hate to say this, but how about legal solutions? If you sell e.g. guns that explode if you use them, you are going to go out of business, EULA or no EULA.
(I guess this mitigation strategy works better in the US than e.g. EU, though.)

Cheers,

-Markus

P.S. Funny datapoints from my home infra:

- 2,5 years old firmware on my CER seems to be holding strong; of course, there are zero open ports to the outside world. Default deny policy makes even broken hardware work. It is the ‘call me to administer’ + weird authz when you get to trouble.

- The VDSL2-ethernet bridge (aka lobotomized ZyXEL router) that is in front of it is using about 5 years old default firmware, and I am still not worried, it does not talk IP.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 3 Nov 2016 20:19:13 +0000

> > Yes, I agree it's possible to do better, but what's the incentive for
> > a bottom-feeding vendor of cheap devices to bother?
> 
> I hate to say this, but how about legal solutions? 

My reading of the tea leaves: either the industry creates its own certification plan, or the regulators will do it for us.
Here is a data point:
https://www.euractiv.com/section/innovation-industry/news/commission-plans-cybersecurity-rules-for-internet-connected-machines/
In the US, both the FCC and FTC are showing keen interest.
I'd rather the industry get there first.
And, BTW, it's also been suggested that devices list their "end of life" date when they're sold. After which no updates may be provided. And remotely-triggered "kill switch" may be used if a bad vulnerability is discovered after that date. 
Another recommendation is default passwords be unique per device, and not easily determined from MAC address, firmware revision, etc., and be changeable. 
That is, it's not just about upgradability. It is also passwords, encryption, and messaging/promises/guarantees that are made.
Just like cars now have seatbelts, front and side airbags, crumple zones, and lemon laws.
There are a number of industry whitepapers coming out on this topic, and conferences/meetings being held. It's all the rage right now. 

Barbara

---

From: Paul Duffy <[email-masked]>
Date: Thu, 3 Nov 2016 16:36:26 -0400

> of cheap devices to bother?

Lawsuits, regulation, well respected security branding (awarded after 
certification testing).

Any or all of the above.

Its got to have impact on the bottom line.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 04 Nov 2016 09:34:09 +0100

Exactly. Same as we have regulations like UL, FCC, EC, etc., the same certifications must care about a minimum set of security, upgradeability, etc., features.

So the extra cost for the vendors is almost cero if we are talking about the same certifications entities, just new test added to the actual sets.

If you don’t comply the certification, your products will not be accepted in customs from a very high number of countries, so you will be somehow forced to follow them.

The question here, is homenet the right venue for creating those minimum requirements?

Regards,
Jordi

-----Mensaje original-----
De: homenet <[email-masked]> en nombre de "STARK, BARBARA H" <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 3 de noviembre de 2016, 21:19
Para: Markus Stenberg <[email-masked]>, Brian E Carpenter <[email-masked]>
CC: Philip Homburg <[email-masked]>, "[email-masked]" <[email-masked]>, Juliusz Chroboczek <[email-masked]>
Asunto: Re: [homenet] write up of time without clocks

    
    Barbara

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Tim Chown <[email-masked]>
Date: Fri, 4 Nov 2016 11:43:32 +0000

Hi,

On 4 Nov 2016, at 08:34, JORDI PALET MARTINEZ <[email-masked]<mailto:[email-masked]>> wrote:

Perhaps contribute to draft-moore-iot-security-bcp-00?

See https://tools.ietf.org/html/draft-moore-iot-security-bcp-00

This was submitted at the Seoul deadline.  Authors copied.

Tim

Regards,
Jordi

-----Mensaje original-----
De: homenet <[email-masked]<mailto:[email-masked]>> en nombre de "STARK, BARBARA H" <[email-masked]<mailto:[email-masked]>>
Responder a: <[email-masked]<mailto:[email-masked]>>
Fecha: jueves, 3 de noviembre de 2016, 21:19
Para: Markus Stenberg <[email-masked]<mailto:[email-masked]>>, Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
CC: Philip Homburg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Juliusz Chroboczek <[email-masked]<mailto:[email-masked]>>
Asunto: Re: [homenet] write up of time without clocks

   Barbara
   _______________________________________________
   homenet mailing list
   [email-masked]<mailto:[email-masked]>
   https://www.ietf.org/mailman/listinfo/homenet

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 04 Nov 2016 13:11:13 +0100

I guess the problem is that this document is NOT targeted to CPEs:

      In principle these requirements apply to all hosts that connect to
      the Internet, but this list of requirements is specifically
      targeted at devices that are constrained in their capabilities,
      more than general-purpose programmable hosts (PCs, servers,
      laptops, tablets, etc.), routers, middleboxes, etc.  While this is
      a fuzzy boundary, it reflects the current understanding of IoT.  A
      more detailed treatment of some of the constraints of IoT devices
      can be found in [RFC7228].

Not sure if we want a separate document, as it seems to me that the requirements are very close or we may need to reword a bit the text above to make it more clear, etc.

Also is BCP the way if we want authorities to mandate it?

Saludos,
Jordi

-----Mensaje original-----
De: homenet <[email-masked]> en nombre de Tim Chown <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 4 de noviembre de 2016, 12:43
Para: "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Keith Moore <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [homenet] write up of time without clocks

    
    Hi,

    On 4 Nov 2016, at 08:34, JORDI PALET MARTINEZ <[email-masked]> wrote:

    

    

    Tim

    Regards,
    Jordi

    -----Mensaje original-----
    De: homenet <[email-masked]> en nombre de "STARK, BARBARA H" <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: jueves, 3 de noviembre de 2016, 21:19
    Para: Markus Stenberg <[email-masked]>, Brian E Carpenter <[email-masked]>
    CC: Philip Homburg <[email-masked]>, "[email-masked]" <[email-masked]>, Juliusz Chroboczek
     <[email-masked]>
    Asunto: Re: [homenet] write up of time without clocks

    

    

       Barbara

    
    This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or
     use of the contents of this information, including attached files, is prohibited.

---

From: Tim Coote <[email-masked]>
Date: Fri, 4 Nov 2016 14:11:35 +0000

This may have negative value, so feel free to throw it out. but..  

An observation from consumer IoT work is the importance of giving the consumer positive feedback that all is well. 

Poor visibility and diagnostics of faults make the cost of supporting any service expensive and erode brand value where users just carry on without realising that something’s wrong in one of the umpteen, hard-to-directly-observe bits of hardware (and software). Having raised awareness of an issue, there’s still the challenge of binding the physical box with the name that’s reporting the problem.

My sense is that trying to engineer a general purpose protocol may not be possible.

So, would it be reasonable for devices that are not sure of the time, to report that fact, and their view of what the time is to the user for acceptance?

tc
> On 4 Nov 2016, at 12:11, JORDI PALET MARTINEZ <[email-masked]> wrote:
>

---

From: "Howard, Lee L" <[email-masked]>
Date: Fri, 4 Nov 2016 14:42:54 +0000

>Not sure if we want a separate document, as it seems to me that the requirements are very close or we may need to reword a bit the text above to make it more clear, etc.

We already have a separate document: https://tools.ietf.org/html/rfc7084 "IPv6 CE Router Requirements"

It says CPE router SHOULD support 6rd and SHOULD support DS-Lite.

Lee

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 04 Nov 2016 16:29:42 +0100

I think we are talking about different issues here, the point is security requirement to avoid the CPEs to be easily “controlled” for attacks …

Regards,
Jordi

-----Mensaje original-----
De: homenet <[email-masked]> en nombre de "Howard, Lee L" <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 4 de noviembre de 2016, 15:42
Para: JORDI PALET MARTINEZ <[email-masked]>, Tim Chown <[email-masked]>, "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>, Keith Moore <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [homenet] write up of time without clocks

    

    

    Lee

---

From: "Howard, Lee L" <[email-masked]>
Date: Fri, 4 Nov 2016 18:17:04 +0000

You're right, I got this confused with another thread.

Lee

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 05 Nov 2016 00:41:42 +0100

> Poor visibility and diagnostics of faults make the cost of supporting
> any service expensive and erode brand value

Point.

> So, would it be reasonable for devices that are not sure of the time, to
> report that fact, and their view of what the time is to the user for
> acceptance?

Well, the obvious solution would be to define one or more HNCP TLV types
that devices MAY publish and that monitoring software SHOULD display in
purple and MAY display in dark red.  I'm a little ambivalent on the subject:

  - on the one hand, HNCP requires every single bloody bit of data to be
    flooded across every single bloody HNCP node in the network; that's
    bloody quadratic scaling with the number of bloody lightbulbs;
  - on the other hand, it's not too difficult to synchronise with HNCP
    without participating in the protocol (one of my students did
    a from-scratch implementation of a passive HNCP monitor last summer,
    and she had no previous exposure to HNCP);
  - on the gripping hand, this is only doable by binding port 8231, so
    only one HNCP peer per host;
  - I'm out of hands, but you probably want your lightbulbs to participate
    in monitoring without being authorised to participate in HNCP.

I definitely think that Homenet is the suitable place to define a lightweight
monitoring protocol that every lightbulb MAY participate in.

-- Juliusz

---

From: Keith Moore <[email-masked]>
Date: Fri, 4 Nov 2016 21:04:13 -0400

>        can be found in [RFC7228].

This might be something we could discuss among the authors of 
draft-moore-iot-bcp.   We literally started talking about the draft last 
Friday, so it was a rush job to get something out by Monday. My feeling 
is that the minimum requirements are valid across pretty much anything 
that connects to the network (including homenet CPEs).  But if we make 
the document too wide in scope, people might miss it.   For instance, 
you and I know what we mean by "Internet hosts" (and that's traditional 
language for the IETF community) but an IoT vendor might never think to 
look at such requirements.   I was recently working with a client 
developing an embedded Internet-connected instrumentation device and I 
had a hard time convincing them that IETF standards (much less IETF 
security standards) were even applicable to their product.

So it might make sense to fork this document sooner or later for 
homenet, but maybe wait until revision -03 or so, so that we have the 
basics collected in one place?   It will be more difficult to manage 
multiple documents in multiple working groups, because I think we'll 
still want to cross-check for consistency to some degree.

> Also is BCP the way if we want authorities to mandate it?

My thinking is that BCP is appropriate for any standard for which 
interoperability cannot be tested.   Otherwise the document would be 
stuck at Proposed Standard forever.

Keith

---

From: Michael Richardson <[email-masked]>
Date: Sat, 05 Nov 2016 00:21:45 -0400

Teco Boot <[email-masked]> wrote:
    > certificate validation, right? I have to deal with stuff lacking a RTC
    > battery. I save system time every now and then in flash. During
    > startup, clock jumps forward to RTC when warm start occurs (main power
    > was not interrupted) or to saved system time when a cold boot
    > occurs. When clock is behind, it jumps forwards when NTP syncs. My
    > certificates do not expire during "powered off, on the shelf".

I was looking for a write up that explained this, that had some thoughts
about threats mitigated, and threats that still exist.  The reason for this,
is mostly for Security Considerations, to argue that even though devices may
not have battery-backed RTCs, they could still have reasonable time.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Sat, 05 Nov 2016 00:26:47 -0400

Philip Homburg <[email-masked]> wrote:
    >> credentials.  This has nothing to do with outdated firmwares.

    > request upnp to open ports to telnet or ssh. But is is impossible to
    > deploy such an update.

    > For consumer electronics, we cannot rely on consumers to actually
    > download and install new firmware. So part of the solution to securing
    > those devices has to be that (out of the box) they will update
    > automatically.

Which in some implementations, means having a clock to know that your current
firmware is actually newer than the "proposed" new firmware (which is really
much older), or knowing that it's been too long since a firmware load.

If update cycle expects a new firmware every 6 months, but at the same time,
won't install firmware older than 1 year, you need a clock.  An attacker that
can force time backwards, can set it back to that time when the telnet port
was open with the default password... (It's not fake firmware afterall, it
has a signature and everything).

And you can't force people to monotonically go up in versions, because bugs
do occur, and people need to "undo"...

    > For the same reason, having lots of devices on the internet that have
    > been abandoned by the vendor is also a huge security risk. So ideally
    > those devices should shutdown automatically.

again, some notion of current time, so the device can reasonably die.
(And in this case, getting too new time might be a threat)

    > update automatically. We need to do the same will all other devices

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

---

From: Philip Homburg <[email-masked]>
Date: Sat, 05 Nov 2016 12:29:22 +0100

>much older), or knowing that it's been too long since a firmware load.

Where I entered the discussion is basically saying that only way to get
secure time on today's internet that sort of scales is to start a TLS
connection with a server you trust.

One thing we could do is to design a secure time protocol, but I doubt that
that is going to fly, and certainly not in the near future.

Another thing would be to adapt security protocols to deal with less secure
or less accurate time. But that requires actually going over DNSSEC and
TSL and possibly other protocols and think about the effects of less 
secure or less accurate time. That can be done, but some working group
would have too actually do the work.

So that leaves me with the conclusion: if you need DNSSEC or TLS for
security purposes, then the only way to be secure is to fetch the time
using TLS from a server you trust.

---

From: Tim Coote <[email-masked]>
Date: Sun, 6 Nov 2016 21:37:56 +0000

> On 4 Nov 2016, at 23:41, Juliusz Chroboczek <[email-masked]> wrote:
> 
Indeed. I find it helpful to keep an eye on how the economics work as they drive poor behaviours and undermine the value of the standards.
> monitoring protocol that every lightbulb MAY participate in.

That works for me as it at least gives something to base a commercial contract on that has the strength of independent standards.
Tim

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 7 Nov 2016 14:13:14 +0200

> do occur, and people need to "undo"...

Undo should always need to be manual operation, preferrably something
like reboot and press factory reset button, and then you can load any
firmware without any checks in. 

For automatic updates, or normal updates done by adminstrative
interface, there is never need to go backwards, i.e., you can force
them to do monotonically go up in version.

Also quite a lot of systems actually keep two firmwares, current and
backup one, so undo operation will simply switch to the backup
version.

There are lots of devices which you cannot downgrade once you have
upgraded them, and people do not really consider them a problem...

I do not even remember when was the last time I needed to downgrade
back to previous version. There has been some versions which have been
buggy, but usually those are fixed by manufacturer, and the fix will
be to load next firmware, not downgrading to old one.
-- 
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 10 Nov 2016 06:25:53 -0800

> On Nov 7, 2016, at 4:13 AM, Tero Kivinen <[email-masked]> wrote:
> 
> back to previous version.

Yesterday, for me.

> There has been some versions which have been

That won't help if the upgrade kills networking, as it did for me yesterday. Not everyone has another way to get to the net to patch this sort of issue.

Joe

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Nov 2016 16:12:37 +0900

Philip Homburg <[email-masked]> wrote:
    >> Which in some implementations, means having a clock to know that your
    >> current firmware is actually newer than the "proposed" new firmware
    >> (which is really much older), or knowing that it's been too long since
    >> a firmware load.

    > One thing we could do is to design a secure time protocol, but I doubt
    > that that is going to fly, and certainly not in the near future.

    > Another thing would be to adapt security protocols to deal with less
    > secure or less accurate time. But that requires actually going over
    > DNSSEC and TLS and possibly other protocols and think about the effects
    > of less secure or less accurate time. That can be done, but some
    > working group would have too actually do the work.

You write TLS, but really, I think you mean PKIX (certificates).
AFAIK, TLS with raw public key or PSK doesn't care about time.

While this might be a pedantic point, I think it's important to be clear
about where the problem is because it reveals that there are TLS uses which
do not have problems, but also that the time problem is not just about TLS
and DNSSEC.

The google work posted earlier in the thread seems to be the protocol you
seek.  But again, my goal was to write up the heuristic that explains how to
get some reasonable time *prior* to getting a default route (because the
device needs to validate certificates to get those routes).

Work items that HomeNet might consider would be "current time" TLVs for PPP(oE),
and DHCP.  Could we find a way to trust them; maybe.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Nov 2016 16:20:45 +0900

Tero Kivinen <[email-masked]> wrote:
    >> And you can't force people to monotonically go up in versions, because
    >> bugs do occur, and people need to "undo"...

    > firmware without any checks in.

yes, you are right, this may well be the right answer for 2016.
I think that as we go more autonomic, and/or more ISP managed, that this
isn't going to fly.

    > backup one, so undo operation will simply switch to the backup version.

More core-ISP devices (i.e. cisco/juniper/brocade/etc. routers) often support
multiple backup firmwares, but it is actually rather common to have to revert
more than one version back... but more particularly, often the right version
isn't the previous version, but instead a version in between the previous
version, and the current version, or worse, a side branch version...

While the above is not a concern for Homenet per-se, I think it is likely
that homenet will get deployed into Internet-dependant small businesses early
as it provides good dual-ISP operation.  

    > upgraded them, and people do not really consider them a problem...

Lots of devices get bricked and go into the waste, and many manufacturers
consider that a feature, but few consumers do.

    > buggy, but usually those are fixed by manufacturer, and the fix will be
    > to load next firmware, not downgrading to old one.

I have regularly had to downgrade the radio firmware in my phone in order to
run the operating system that I wanted.  From the baseband CPUs point of
view, the host system is not always that trusted.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 13 Nov 2016 16:25:08 +0900

Keeping just the relevant parts, sorry the attribution has gotten lost:

> So, would it be reasonable for devices that are not sure of the time,
> to report that fact, and their view of what the time is to the user
> for acceptance?

The above proposes an HNCP TLV to communicate a fault from a particular
device.

My impression is that the rest of the thread is about an HNCP TLV that would
contain software versions for each device that participates.

Tim wrote:
    > That works for me as it at least gives something to base a commercial
    > contract on that has the strength of independent standards.  Tim

But, I didn't understand which part he was referring to.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 13 Nov 2016 13:34:27 +0100

>do not have problems, but also that the time problem is not just about TLS

My reasoning was the following:
Assume a device that has no idea about time when it boots. 
Assume that some security protocols (DNSSEC, TLS most of the time, etc) have
as a requirement secure, somewhat accurate time. 

So we need a protocol that allows the device to fetch the current time in
a way that doesn't allow an attacker to interfere.

Now also let's assume todays internet. We can design fancy new time protocols,
but if they take decades to deploy then it doesn't do much good.

So a very simple protocol to obtain secure time is to have the device ask
a preconfigured server. This protocol then needs to have two properties:
- The time returned by the server has to be authenticated and integrity
  protected (and the device has to be able to verify this)
- The timestamp has to be fresh (and the device has to verify this)

So this can easily be implemented using standard protocols such as HTTPS:
- The device needs to have a long lasting certificate for the server
  (lasting long enough that time irrelevant)
- The device has to be configure to require forward secrecy, or any other
  TLS configuration that guarantees that replay is impossible.
- The device issues a simple 'GET /' and gets the current time back in
  the response header.

So if you want to bootstrap secure time today, this is an easy way to use
existing protocols.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Nov 2016 09:23:32 +0900

Philip Homburg <[email-masked]> wrote:
    >> While this might be a pedantic point, I think it's important to be
    >> clear about where the problem is because it reveals that there are TLS
    >> uses which do not have problems, but also that the time problem is not
    >> just about TLS and DNSSEC.

    > My reasoning was the following: Assume a device that has no idea about
    > time when it boots.  Assume that some security protocols (DNSSEC, TLS
    > most of the time, etc) have as a requirement secure, somewhat accurate
    > time.

Yes, I wasn't faulting your reasoning, rather I was trying to decouple the
use of the term "TLS" from the real requirement, which is that TLS using
certificates requires time, because the certificates have expiry dates.

I assume you saw the reference to:
  https://roughtime.googlesource.com/roughtime

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Nov 2016 17:06:04 +0900

Of course, we _want_ certificates to expire and be renewed.   So
reducing the window of vulnerability that devices with no RTCs is
worth doing; using protocols that do not allow for time-based
rejection of authentication information is worse than using a rough
estimate of the time if we don't have an accurate clock.