Re: [perpass] Tiny stacks

Joseph Lorenzo Hall <joe@cdt.org> Tue, 10 December 2013 17:24 UTC

Return-Path: <joe@cdt.org>
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 5C3211ADFAB for <perpass@ietfa.amsl.com>; Tue, 10 Dec 2013 09:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 7fxVR0TpuxYt for <perpass@ietfa.amsl.com>; Tue, 10 Dec 2013 09:24:48 -0800 (PST)
Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id EA7241ADF74 for <perpass@ietf.org>; Tue, 10 Dec 2013 09:24:47 -0800 (PST)
X-Footer: Y2R0Lm9yZw==
Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for perpass@ietf.org; Tue, 10 Dec 2013 12:24:41 -0500
Message-ID: <52A74E58.4000708@cdt.org>
Date: Tue, 10 Dec 2013 12:24:40 -0500
From: Joseph Lorenzo Hall <joe@cdt.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: perpass@ietf.org
References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> <CAL02cgRYNNC7Emx=98a621PTPHDweLRTc=wjVhpRo-5yhVD=-Q@mail.gmail.com> <52A65049.2070903@cs.tcd.ie> <52A66042.9060801@gmail.com> <CAMm+LwhQXewmAX4-uAVABRs64cTcS3jiNx1nReUh+Q6B9HCH-w@mail.gmail.com>
In-Reply-To: <CAMm+LwhQXewmAX4-uAVABRs64cTcS3jiNx1nReUh+Q6B9HCH-w@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Subject: Re: [perpass] Tiny stacks
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: <http://www.ietf.org/mail-archive/web/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: Tue, 10 Dec 2013 17:24:50 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


On 12/9/13 7:43 PM, Phillip Hallam-Baker wrote:
> What we can do about this in the IETF is quite limited. What we
> could do is to have some sort of device registration protocol
> whereby the device gains access to the network by first proposing a
> 'contract' specifying all the ports and protocols it is going to
> speak. The network infrastructure could then default-deny any
> access outside that contract.
> 
> This would then reduce the audit task from observing the behavior
> of the device to checking the facilities it asks for and seeing if
> they are acceptable.

I have been thinking similarly... sort of a standards-supported
network monitor for the internet of things:

from p. 4 of
https://www.cdt.org/files/pdfs/CDT-Internet-of-Things-Comments.pdf:

"There may be technological solutions to these barrier-crossing issues
that consumers can configure to control the amount and nature of data
transmitted by IoT-capable sensors and devices in sensitive locations.
For example, it may be possible to design “middleware” networking
equipment that a member of the household or business could configure
to selectively allow or disallow networked objects from communicating
outside of the household network. Ideally, such a privacy appliance
could easily identify data emitted by IoT-capable products in the home
network, but that relies on manufacturers inserting the right tags into
their network communication that such an appliance could read. This
would probably require significant standards work and manufacturer
buy-in (or a legislative or regulatory mandate) to support this kind
of functionality. Another option may be to design a standard element
to the networkable components of IoT objects — say a pull-off tab or
shielding element — that consumers can activate in order to toggle or
disable networking functionality. Given that certain activities and
areas in one’s home are particularly sensitive towards arbitrary data
collection — bedrooms, bathrooms, children’s areas — there may be a
level of tracking and data usage that above which is simply not
appropriate for those products or that industry commits to making
connected and disconnected versions."

Would love to know if there is work (standards, research, whatever) in
this area I should be aware of.

best, Joe

- -- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
joe@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSp05YAAoJEF+GaYdAqahx388P/3Mg/JTS5SOqpjdKLakv3+dm
PyjbV2IZgojQI/x6bQO7JBggSo5djess7GzK2BdKH5U8gzSHv4Q7+OXYEooiO+c/
01QC0vJCO7mCw3Sr0hfpRB1s59cIimqR44yNT1bi0R3EU6d1e+l3UGftqOlBrQ6O
IU6yp0puY9lXsZ6S6vY5zIbKwpGDsCBAaqx7872VEwjjKEnf0yDsmQsur1xe4vGt
AF1G64kwq5brGjCz0plAcawDU4ljoOBHSaCaxcXt1co4fJzM1EcsrRKKg3dZruRr
aEDDKuFO6oHv4mtHmG//54XXSglEXnaaVs1tPCFevXTUgdBtooKVhmj26xoTe4i6
FtT9p0LUtY01UMzNz9KtmvYG1LvCjKScx86lqFb7In2sOcrPTngx6f8mxbTzzSMF
SL1UWqjHazeWuIQtSVk2mSuYvlT/Ja9eQ+p/BRYcQdKF5e/koezuTclP+2DTWITd
iX6JNuUY9msEaL9e0/8glioT7DC+maBLX06rsuXzWZ3OenNLxLW3eINgxYq1469O
3e2TLa29uM3UnC/ya61bsLMVlx9wy169O6iuZA6g78e6cN11CYzf0JewGidhZ5sA
/vuQXZ5ChLtMhrJPOlzJmA9HLqQ9mXrUbdKwRvABjaBimehcb8geYloae4WwQEtF
JoIicWI8Yf2OqCzsOI3x
=RYCM
-----END PGP SIGNATURE-----