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

SM <sm@resistor.net> Fri, 06 December 2013 09:36 UTC

Return-Path: <sm@resistor.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 C92311AD93D for <perpass@ietfa.amsl.com>; Fri, 6 Dec 2013 01:36:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] 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 J3gfHtdj-F7p for <perpass@ietfa.amsl.com>; Fri, 6 Dec 2013 01:36:57 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB951AD8F1 for <perpass@ietf.org>; Fri, 6 Dec 2013 01:36:57 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB69acv0029523; Fri, 6 Dec 2013 01:36:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386322603; bh=DA5UNFQ1WTCq+lisj9RyTlFM99XXiwOtnyfeRUTHNDA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0fddMUIBSNdKE2s0x7tTeUlVFHqkjNdB2KLZxDjCrjkloIfPXQ0fxQGhfulfiSh0u yFh4nETr2FApRkPyCGOS4b61detJxYBzo08+ieYRom+Wi9i29hgneirIPRMsuGeJuW SXpBow4OyPUhOOBu3HSg/lnoIIJOHK8G8c02uwKg=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1386322603; i=@resistor.net; bh=DA5UNFQ1WTCq+lisj9RyTlFM99XXiwOtnyfeRUTHNDA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2iwVhK9l6qLe51s9BrcCah7wbHJWKb7/yqB7zTEcTqnM5T4mjUoqLX0J9WWSr3wK6 K9sy/r4rEs7UhcrMt4TufBrdhYwmzXGv6FmYj7etXexSfOHsLmxKvtvTD4JVxFGklG c10lS1+9pPdx1op67cv5y81I7EZXv7WN61gOT9uo=
Message-Id: <6.2.5.6.2.20131206000507.0bdb7c20@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 06 Dec 2013 01:20:17 -0800
To: Pranesh Prakash <pranesh@cis-india.org>
From: SM <sm@resistor.net>
In-Reply-To: <52A15835.2070901@cis-india.org>
References: <E2DA1477-C86E-441E-A33D-D47A0D67AFF3@iab.org> <EF9BD1E4-6EF3-4035-AC4E-1A2D3CADE615@mnot.net> <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: perpass@ietf.org, Bruce Perens <bruce@perens.com>
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: Fri, 06 Dec 2013 09:36:59 -0000

Hi Pranesh,
At 20:53 05-12-2013, Pranesh Prakash wrote:
>This is not a debate about whether surveillance is good or not.
>(Targetted surveillance which is allowed by a law, has a legitimate aim
>in a democratic society, is not arbitrary, is necessary to achieve those
>aims, is proportionate, authorized by a judicial process, etc., would be
>legitimate.)  This is a debate about whether it is technically (and
>politically) desirable for protocols to prevent mass surveillance.

I read 
http://cis-india.org/internet-governance/blog/indias-big-brother-the-central-monitoring-system 
There are likely similar cases in other countries.

What could be the effect if (widely deployed) IETF protocols 
prevented such systems from working?  It is possible to design a 
protocol which does not allow "in the clear" traffic [1].  It is not 
clear whether such a protocol would be widely deployed.

>There is no reason why the 'default' insecurity of HTTP cannot be
>handled at the technical level.  Do I believe all HTTP2 traffic MUST be
>encrypted?  Perhaps, and perhaps not.  But most certainly, the 'default'
>for HTTP2 traffic should be encryption.

Ok.

Regards,
-sm

1. That is different from the "default".