Re: [perpass] US intelligence chief says we might use the IoT to spy on you

"Olle E. Johansson" <oej@edvina.net> Fri, 12 February 2016 16:57 UTC

Return-Path: <oej@edvina.net>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D281A6FB0 for <perpass@ietfa.amsl.com>; Fri, 12 Feb 2016 08:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPtJtrjM6TIh for <perpass@ietfa.amsl.com>; Fri, 12 Feb 2016 08:57:49 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 851421A6F33 for <perpass@ietf.org>; Fri, 12 Feb 2016 08:57:46 -0800 (PST)
Received: from [192.168.40.17] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 6897093DE5C; Fri, 12 Feb 2016 16:56:51 +0000 (UTC)
Content-Type: multipart/signed; boundary="Apple-Mail=_B989D43F-7B26-4C53-8FBC-17F3C65CED6B"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <56BE0CE3.9010901@dcrocker.net>
Date: Fri, 12 Feb 2016 17:57:41 +0100
Message-Id: <5AAF7407-BA28-49F7-B54A-C3019889879E@edvina.net>
References: <D2E1E4F0.3C6A1%harper@isoc.org> <946B2223-C0BD-4AFE-AE76-99478609104F@vigilsec.com> <56BCA55E.2020205@cs.tcd.ie> <0cbc01d164fb$88b09da0$9a11d8e0$@huitema.net> <56BCD7B9.9070902@dcrocker.net> <CAPt1N1nTZwzTQxFk7FjASo0qL_U_aSh=N2wX2rkrh=xbz5pRCg@mail.gmail.com> <56BDED05.4030102@dcrocker.net> <760A207E-F060-4347-92C0-EA5E8AA11EF9@isoc.org> <EE755B4B-D18D-4AAE-ACB5-481149059B67@edvina.net> <56BE0CE3.9010901@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/perpass/PYH5eGW0QMWG7k3zTzW_MirW_Q4>
Cc: Dan York <york@isoc.org>, perpass <perpass@ietf.org>, Olle E Johansson <oej@edvina.net>
Subject: Re: [perpass] US intelligence chief says we might use the IoT to spy on you
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perpass/>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Feb 2016 16:57:53 -0000

> On 12 Feb 2016, at 17:48, Dave Crocker <dhc@dcrocker.net>; wrote:
> 
> 
> 
> On 2/12/2016 8:24 AM, Olle E. Johansson wrote:
>>> On 12 Feb 2016, at 17:14, Dan York <york@isoc.org
>>> <mailto:york@isoc.org>> wrote:
>>>> On Feb 12, 2016, at 9:32 AM, Dave Crocker <dhc@dcrocker.net
>>>> <mailto:dhc@dcrocker.net>> wrote:
>>>> I do not know of any reason the model for IoT needs to be different
>>>> from email.  That is, yes, servers are needed.  They might reside
>>>> with end-users, but they do not have to.
> ...
>>> You're right, Dave, that this is quite similar to email... people
>>> *could* operate their own home email servers, or they could just use
>>> some big cloud-based vendor (<insert favorite name here>).
>> There is a technichal issue that also drives vendors to the cloud. As
>> long as we have NAT, we won’t be able to reach the stuff in the home
>> with apps on a mobile device. We need to come up with some sort of
>> standardized “back to my mac” like platform that works both over IPv4
>> and IPv6 with a security architecture that is trustworthy.
> 
> There are a number of separate issues:
> 
> 1. For rendez-vous, such as the user being mobile and wanting to contact or monitor their IoT environment, there has to be some way for the user to 'find' the IoT environment from over the public Internet.  (A rendez-vous function is independent of any storage-and-analysis function.)
> 
> 2. Other than users accessing their IoT environment from the Internet, what services are /required/ for IoT operation and involving a server -- on the public Internet or on the user's network?  What dictates using the public Internet?
> 
> 3. From what I'm seeing, nothing technical requires the public server to be owned or operated by the IoT equipment vendor.  Nothing technical restricts the server from being a public, commodity opportunity.
> 
> Note that these issues are not restricted to  -- or new to -- IoT and that while rendez-vous does require some sort of public server (given address translation barriers at the user's network) it does not require the server on the Internet to be owned or operator by the IoT equipment vendor.
Right. Techies like us understand that - but the average user?
> 
> 
>> But as stated below, this will not happen without significant market
>> pressure. I work a bit
>> in the health care area and every vendor is building their own systems,
>> which will drive
>> public spending up through the roof at the same time as it causes severe
>> issues with
>> regards to privacy laws - data flowing in uncontrolled ways, ending up
>> on clouds anywhere
>> on the planet provided by more or less unknown vendors. Hopefully the
>> public sector
>> can control their spending and force some change in this area.
> 
> Vendor lock-in has problems that are worse than just cost.  It significantly increases the likelihood of systemic vulnerabilities, since lack of transparency in the design, development, testing and operation of the services means far less, and far less varied, review. For an environment subject to the degree of information accountability that the health industry has, I'd expect this to be a very serious problem, indeed.
> 
> A coalition of consuming groups with similar concerns might be enough to press for open protocols and a free market for public servers and services.
Mmm.
> 
> 
>>>> I think the real issue here is that the vendors have a strong
>>>> incentive to /retain/ their data acquisition role.  So they won't
>>>> give it up unless and until there is a strong consumer-driven
>>>> pressure for it.
>>> 
>>> ... I think you're right on target here.  I think with IoT consumer
>>> devices we're still in the early deployment stages where the vendors
>>> are trying to capture the ecosystem and obtain de facto standards
>>> purely by market success.
> 
> It is worth remembering that commercial networking used to be entirely proprietary.
+1
> 
> The move towards open standards and public networks was not a vendor initiative.  It came about only because of consumer and enterprise demand.
> 
> 
>> I think we need a showcase of an architecture that works to show
>> vendors that don’t want to play that game and as a proof if vendors
>> claim it doesn’t work without their wonderful superfantastic cloud
>> service connected to Google, Facebook et al. Customers/users need
>> good examples and today there are not that many out there.
> 
> The challenge is that open efforts tend to move slower and produce less functionality.  That doesn't make them very appealing as an alternative. So they need to provide some other benefit that is very strongly appealing.
> 
> While, yes, R&D and proof-of-concept can be useful here, I think the deeper challenge is to find and exploit consumer leverage.
> 
> In the case of networking, the need to have an environment in which a consumer/enterprise network permitted interoperability among products from different vendors, and interoperability across administrative domains, is what produced the market pressures.

There is interesting stuff happening in the Open Source area. We need to invite them to the IETF and play around so that they understand there’s a need for Open Protocol development here as well. I’ve played a lot with a platform called Domoticz on a Raspberry Pi -it has a lot of tools to connect with just about anything - push services, other protocols (via MQTT) and a lot of bits and pieces that interconnects various radios and equipment. There are many platforms like this out there and they do miss the accessability outside of the NAT in an easy to use and stable way.

My wife asks me why she can’t check the temperature of the fridge from her office. I can try to go down a lot of hacks to enable that, but feel I miss a more standardized generic way of solving the problem.

What’s also missing in these platforms is security. Maybe one should try to analyze what pieces are missing and what can be provided from the IETF smörgåsbord.

Food for thought.

/O