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-----
- [perpass] Commnets on draft-farrell-perpass-attac… l.wood
- Re: [perpass] Commnets on draft-farrell-perpass-a… Ted Lemon
- Re: [perpass] Commnets on draft-farrell-perpass-a… Bruce Perens
- Re: [perpass] Commnets on draft-farrell-perpass-a… Phillip Hallam-Baker
- Re: [perpass] Commnets on draft-farrell-perpass-a… l.wood
- Re: [perpass] Commnets on draft-farrell-perpass-a… Ted Lemon
- Re: [perpass] Commnets on draft-farrell-perpass-a… Theodore Ts'o
- Re: [perpass] Commnets on draft-farrell-perpass-a… Hannes Tschofenig
- Re: [perpass] Commnets on draft-farrell-perpass-a… Bruce Perens
- Re: [perpass] Commnets on draft-farrell-perpass-a… Bruce Perens
- Re: [perpass] Commnets on draft-farrell-perpass-a… Mark Nottingham
- Re: [perpass] Commnets on draft-farrell-perpass-a… Bruce Perens
- Re: [perpass] Commnets on draft-farrell-perpass-a… Jacob Appelbaum
- Re: [perpass] Commnets on draft-farrell-perpass-a… Bruce Perens
- Re: [perpass] Commnets on draft-farrell-perpass-a… Jacob Appelbaum
- Re: [perpass] Commnets on draft-farrell-perpass-a… Phillip Hallam-Baker
- Re: [perpass] Commnets on draft-farrell-perpass-a… Bruce Perens
- Re: [perpass] Commnets on draft-farrell-perpass-a… Stephane Bortzmeyer
- Re: [perpass] Commnets on draft-farrell-perpass-a… Josh Howlett
- Re: [perpass] Commnets on draft-farrell-perpass-a… Stephen Farrell
- Re: [perpass] Commnets on draft-farrell-perpass-a… Josh Howlett
- Re: [perpass] Commnets on draft-farrell-perpass-a… Stephen Farrell
- Re: [perpass] Commnets on draft-farrell-perpass-a… Josh Howlett
- Re: [perpass] Commnets on draft-farrell-perpass-a… Stephen Farrell
- [perpass] Tiny stacks Brian E Carpenter
- Re: [perpass] Tiny stacks Richard Barnes
- Re: [perpass] Tiny stacks Robin Wilton
- Re: [perpass] Tiny stacks Paul Ferguson
- Re: [perpass] Tiny stacks Hannes Tschofenig
- [perpass] Way forward? [Was: Tiny stacks] Martin Millnert
- Re: [perpass] Tiny stacks Brian E Carpenter
- Re: [perpass] Tiny stacks Phillip Hallam-Baker
- Re: [perpass] Tiny stacks Richard Barnes
- Re: [perpass] Tiny stacks Martin Thomson
- Re: [perpass] Tiny stacks Stephen Farrell
- Re: [perpass] Tiny stacks Richard Barnes
- Re: [perpass] Tiny stacks Bjoern Hoehrmann
- Re: [perpass] Tiny stacks Richard Barnes
- Re: [perpass] Tiny stacks Stephen Farrell
- Re: [perpass] Tiny stacks Stephen Farrell
- Re: [perpass] Tiny stacks Brian E Carpenter
- Re: [perpass] Tiny stacks Phillip Hallam-Baker
- Re: [perpass] Tiny stacks Stephen Farrell
- Re: [perpass] Tiny stacks Phillip Hallam-Baker
- Re: [perpass] Tiny stacks Robin Wilton
- Re: [perpass] Tiny stacks Joseph Lorenzo Hall
- Re: [perpass] Tiny stacks Scott Brim
- Re: [perpass] Tiny stacks Scott Brim
- Re: [perpass] Tiny stacks Phillip Hallam-Baker
- Re: [perpass] Tiny stacks Dean Willis