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

Dave Crocker <dhc@dcrocker.net> Fri, 12 February 2016 16:21 UTC

Return-Path: <dhc@dcrocker.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 E972B1A6EED for <perpass@ietfa.amsl.com>; Fri, 12 Feb 2016 08:21:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CU16d1ws9U16 for <perpass@ietfa.amsl.com>; Fri, 12 Feb 2016 08:21:02 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3134B1A6EF0 for <perpass@ietf.org>; Fri, 12 Feb 2016 08:20:59 -0800 (PST)
Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u1CGKwwV029032 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 12 Feb 2016 08:20:58 -0800
To: Dan York <york@isoc.org>
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>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <56BE0669.9000701@dcrocker.net>
Date: Fri, 12 Feb 2016 08:20:57 -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: <760A207E-F060-4347-92C0-EA5E8AA11EF9@isoc.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 12 Feb 2016 08:20:58 -0800 (PST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/perpass/EAZChh38aGloYCO0ZcNCKeRescg>
Cc: perpass <perpass@ietf.org>
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
Reply-To: dcrocker@bbiw.net
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:21:04 -0000

On 2/12/2016 8:14 AM, Dan York wrote:
> To Ted's point, what I think we're seeing is a very large number of
> vendors pursuing the "Device-to-Cloud" model (section 2.2) of sending
> all the data back to some central application service provider, versus
> the "Device-to-Gateway" model (2.3) where there is a local hub in the home.


As email has demonstrated over many years, these are choices in 
operational configuration, but need not be choices in protocol.

That said, one might argue that SUBMIT vs. SMTP demonstrate email's 
moving toward a similar distinction, but I'm inclined to say it doesn't. 
  For the current discussion, the issue is equivalent to asking where 
the SUBMIT server is.  And the technical answer is: anywhere, and run by 
anyone.

I do not see a technical or operational reason for IoT to impose a 
different range of choices.

The business issues are an entirely separate matter, but for now the 
result is both a loss of choice in privacy /and/ vendor lock-in.

d/