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

S Moonesamy <sm+ietf@elandsys.com> Wed, 04 December 2013 14:28 UTC

Return-Path: <sm@elandsys.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 894191AE274 for <perpass@ietfa.amsl.com>; Wed, 4 Dec 2013 06:28:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level:
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, 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 VKuDvEg8WdMC for <perpass@ietfa.amsl.com>; Wed, 4 Dec 2013 06:28:16 -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 4CE821AE272 for <perpass@ietf.org>; Wed, 4 Dec 2013 06:28:16 -0800 (PST)
Received: from SUBMAN.elandsys.com ([197.224.137.184]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB4ERvgR011809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Dec 2013 06:28:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386167291; bh=Wvr5ErEr8LWa2kFV+CaNku4WIlXG0pgkgKjeBA1YFhY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tbvAQaHDn/OLBIpQbXiFtOiY/E7xkY/zk6inrQ7W1p0NGxOtrXWgGTGsEXtWIlkEi VSwBAjgl9zYMoRu//+0CrH+KqDGG1bqO1SCSWX4AEnlN5Kw+H4WT97OZMBhbfWGtmf 7ZGYcreptNbwLaID7xjiMaMXQPlu33C30BP42FHs=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1386167291; i=@elandsys.com; bh=Wvr5ErEr8LWa2kFV+CaNku4WIlXG0pgkgKjeBA1YFhY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=x3DGl39puQbFiUkzdXPWsNm/6Oo8xQr8UgP7HlON3oa9iQ5aOYLIaWMP01/83G46v zbnF7ogkQoUfTxrh9eyJvqsMwaxbNwRIhtlSgtSdrRCP+V6PybCsnTiDLNr5fI58kD IF7hSEdMNW5Fl00ZCpLx74lR47fdHXc5kCmW1ISo=
Message-Id: <6.2.5.6.2.20131204040355.0c2fae10@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 04 Dec 2013 06:08:48 -0800
To: Martin Millnert <martin@millnert.se>, Bruce Perens <bruce@perens.com>, Stephane Bortzmeyer <bortzmeyer@nic.fr>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <1386151640.22570.70.camel@galileo.millnert.se>
References: <E2DA1477-C86E-441E-A33D-D47A0D67AFF3@iab.org> <EF9BD1E4-6EF3-4035-AC4E-1A2D3CADE615@mnot.net> <529E8494.7000806@perens.com> <1386151640.22570.70.camel@galileo.millnert.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: perpass@ietf.org
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: Wed, 04 Dec 2013 14:28:17 -0000

Hi Martin, Bruce, Stephane,
At 02:07 04-12-2013, Martin Millnert wrote:
>For the other, mostly technical, arguments put forth by you:
>
>   p3. A sovereign entity may outlaw technical protocol X:
>   It wouldn't be a sovereign entity if it couldn't.  It could outlaw Pi
>= 3.1459... for all I care.  Point is we should not let a single
>Sovereign Entity outlaw the correct definition of Pi, for the rest of
>us. It is precisely within IETF's jurisdiction to define our global
>common Internet communication protocols.  If a single backwards
>Sovereign Entity held veto power over this we would be much poorer
>today. Instead the backwards sovereign entities will have to live
>without these protocols, which is what they in their sovereignty decided
>anyway, so everybody would be happy...

Someone mentioned in a non-IETF discussion that there was a precedent 
about a technical question which might fit the above (3.146) 
argument.  It was recently mentioned in a news article that there is 
a public misconception about the Internet.  In my opinion it would be 
politically inappropriate for the IETF to state that some country 
would have to live without a protocol.

On page 1 of the document, it is mentioned that it is a:

   "deliberate attempt to defeat the correct technical operation of 
the Internet.
    In this case, the feature of communications privacy"

I would use "confidentiality" instead of "communications privacy" 
[1].  I agree that, as it is argued in the document, "attack" has a 
different meaning.

It is difficult to ignore the context.  I posted a draft (see 
http://tools.ietf.org/html/draft-moonesamy-traffic-peeking-00 
).  I'll be candid; the objective of a spying organization is to 
spy.  An in-depth discussion of that will alienate some IETF 
participants.  Not saying anything about [I don't know what word to 
choose] is an alternative.  Another alternative is to look at how the 
political problem affects the technical one.

The document argues that there is "no technical solution to this 
conundrum".  I agree to that.  An interesting point (in the document) 
is that "universal encryption of HTTP connections proposed on the 
working group mailing lists would hinder the technical operation of 
the internet".  I'd say yes.  In my opinion there are reasons why a 
person would consider having encrypted access to "static 
content".  For example, the "in the clear" access might disclose 
information which the user might be uncomfortable about.  One 
alternative is to provide the user and the other parties involved in 
the communication session with choices.  As Martin Millnert pointed 
out, providing those choices is not straight-forward.

I'll adapt a comment from Stephane Bortzmeyer:

   Is it okay to ask Mr Smith to decide based on the information 
[being provided]?

Or to put it differently, should a technical specification provide 
some guidance about that.

Regards,
S. Moonesamy

1. Credits to the Stephen Farrell and I'll take the blame if it is 
incorrect. :-)