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

Dave Crocker <> Fri, 12 February 2016 16:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 84D4F1A6F91 for <>; Fri, 12 Feb 2016 08:48:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id opP5ZZH71h_m for <>; Fri, 12 Feb 2016 08:48:46 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7C451A6FAC for <>; Fri, 12 Feb 2016 08:48:46 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u1CGmaed029657 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 12 Feb 2016 08:48:36 -0800
To: "Olle E. Johansson" <>, Dan York <>
References: <> <> <> <0cbc01d164fb$88b09da0$9a11d8e0$> <> <> <> <> <>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Fri, 12 Feb 2016 08:48:35 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Fri, 12 Feb 2016 08:48:36 -0800 (PST)
Archived-At: <>
Cc: perpass <>
Subject: Re: [perpass] US intelligence chief says we might use the IoT to spy on you
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Feb 2016 16:48:48 -0000

On 2/12/2016 8:24 AM, Olle E. Johansson wrote:
>> On 12 Feb 2016, at 17:14, Dan York <
>> <>> wrote:
>>> On Feb 12, 2016, at 9:32 AM, Dave Crocker <
>>> <>> 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 

> 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.

>>> 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 

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.