[iot-wg] "The Internet of Threats: Fighting FUD with MUD"

Töma Gavrichenkov <ximaera at gmail.com> wrote:
    > Previously on topic: we've agreed (haven't we?) that MUD is not
    > currently targeting industrial IoT and connected health. So, smart
    > homes.

The authors of the MUD specification have specific industrial uses in mind.

    > (By the way, it is more proper to directly specify the issue you're
    > handling before proposing a solution. As MUD doesn't solve the

In a 15 minute presentation, there isn't time for that.
If you'd like to have a longer conversation, that would be great.

    > The issue with smart homes, wearables etc. is that a contemporary
    > commodity IoT device is not connected to the Internet in order to
    > really provide a service to the customer. Instead, it collects,
    > processes and sends data and telemetry which is precious for its
    > vendor, which said vendor would then be able to sell.

I agree that there are many devices like this.
If the device provides no value to end user, then the garbage bin is probably
the appropriate security.  Vote with your wallet.

    > Expecting a vendor to cut their own cables themselves is a strange
    > move, isn't it. Hence, "default policy is no access" stuff isn't just
    > going to fly.

The purpose of the MUD file is to encode the list of acceptable destinations,
and without such a file, there is no access.  So, if it is acceptable to the
end user that their vacuum cleaner maps out their house, then they can enable
the access.  The purpose of this work is keep the vacuum cleaner, when
compromised, from being used to attack the infrastructure of the Internet.

    > And, setting a firewall will only slightly help because of countless
    > reasons.

    > a) We have agreed today (haven't we?) that an IoT device needs to be
    > updated frequently, and probably via the Internet. Let's now phrase it
    > in a different way: we have agreed that an IoT device has a right to
    > connect to a server of its vendor and exchange encrypted data with
    > that server. Good luck telling updates from telemetry streaming then.

If the vendor wants to hide telemetry inside firmware updates, that's okay.
That's not the goal.

    > b) Given a), a vendor will have an 100% legitimate excuse for denying
    > you a service (i.e. remotely switching off a device, or more
    > precisely, *not switching it on*) if the device doesn't have an
    > Internet connectivity.

Agreed.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: </ripe/mail/archives/iot-wg/attachments/20181019/e9112c0f/attachment.sig>