Re: [perpass] perens-perpass-appropriate-response-01

Bruce Perens <bruce@perens.com> Sat, 07 December 2013 07:46 UTC

Return-Path: <bruce@perens.com>
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 CF2491AE074 for <perpass@ietfa.amsl.com>; Fri, 6 Dec 2013 23:46:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.177
X-Spam-Level:
X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RP_MATCHES_RCVD=-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 dkShzO3z-fvg for <perpass@ietfa.amsl.com>; Fri, 6 Dec 2013 23:46:03 -0800 (PST)
Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id E584F1AE039 for <perpass@ietf.org>; Fri, 6 Dec 2013 23:46:03 -0800 (PST)
Received: from [192.168.1.178] (66-214-223-54.static.reno.nv.charter.com [66.214.223.54]) by alchemy.perens.com (Postfix) with ESMTPSA id A9554500084; Fri, 6 Dec 2013 23:45:57 -0800 (PST)
Message-ID: <52A2D24F.4090505@perens.com>
Date: Fri, 06 Dec 2013 23:46:23 -0800
From: Bruce Perens <bruce@perens.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131005 Icedove/17.0.9
MIME-Version: 1.0
To: John Wroclawski <jtw@csail.mit.edu>, perpass <perpass@ietf.org>
References: <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <BC888A6F-F048-4BA6-92F4-8812753F8534@icsi.berkeley.edu> <52A2235A.2030801@perens.com> <ADD6858C-7548-479E-BB71-316E9C52F812@icsi.berkeley.edu> <c97f3134-eedf-44e1-880c-147efb172fc6@email.android.com> <CA+BZK2owfZuePi0kNe9ciVhpW95tSpwjq227u2jTj7ofc5kv-w@mail.gmail.com> <usl4a9lqfifltsv9gubnivpkkc5fufom58@hive.bjoern.hoehrmann.de> <AC664138-104F-47ED-B192-37968C549EF0@csail.mit.edu>
In-Reply-To: <AC664138-104F-47ED-B192-37968C549EF0@csail.mit.edu>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Subject: Re: [perpass] perens-perpass-appropriate-response-01
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: Sat, 07 Dec 2013 07:46:05 -0000

John,

Of course I have sympathy for all of those who have their human rights abridged, and would not begrudge them the use of Tor, preferential https, or whatever helps. I am not sanguine that encryption is any barrier to NSA due to the ASIC issue previously discussed, but it might well be a barrier to religious extremist oppressors, etc.

The problem with security is that however much you have is never enough, because there's always a new threat. And that is exactly why the United States is pursuing a continuously increasing war in whiich surveilance and odious security procedures only increase. And thus IETF will also end up on a continuously increasing war in which odious security procedures only increase, in response.

The next step after encrypting every web query is locking down the browser to the "trusted platform" and insisting on identifying certificates for all users. Our various corporate totalitarians are sure to want it, it already exists on the iPhone and other DRM platforms, and will only get tighter.

So, this ends with the death of the open web.

At some point, we have to draw a line and say this is enough, it doesn't really protect us, it protects someone else at our expense.

Where do you propose to do that? Right after _this_ change? And when the next proposal is to draw the line right after the _next_ change, and so on ad infinitum?

So, I don't want to be forced onto this next security upgrade. I want to be able to intelligently decide whether I need it and when, and to control whether I use it, and when to dispense with it when it's being used for things that are not in my interest.

    Thanks

    Bruce