Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 05 December 2013 11:10 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 8CEB31ADF38; Thu, 5 Dec 2013 03:10:05 -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, RP_MATCHES_RCVD=-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 t6ARzWjCX7ZT; Thu, 5 Dec 2013 03:10:01 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC4B1ADF26; Thu, 5 Dec 2013 03:10:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 10558BEE1; Thu, 5 Dec 2013 11:09:57 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzKXkXgTL8RS; Thu, 5 Dec 2013 11:09:56 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C497ABE8B; Thu, 5 Dec 2013 11:09:56 +0000 (GMT)
Message-ID: <52A05F05.3040506@cs.tcd.ie>
Date: Thu, 05 Dec 2013 11:09:57 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Josh Howlett <Josh.Howlett@ja.net>
References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <CEC5F4B3.1282E%Josh.Howlett@ja.net>
In-Reply-To: <CEC5F4B3.1282E%Josh.Howlett@ja.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: perpass <perpass@ietf.org>, IETF Discussion <ietf@ietf.org>
Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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: Thu, 05 Dec 2013 11:10:05 -0000

Josh,

On 12/05/2013 10:53 AM, Josh Howlett wrote:
> 
> I fully support action to increase security, where it responds to the
> prevailing threat environment. But it will be a perpetuation of the
> naivety that has characterised this debate to think that this alone will
> halt pervasive monitoring, because the threat is not technical in nature.

Personally, I think anyone using the argument that "you can't solve
the problem therefore do nothing" is talking about the same amount
of nonsense as anyone who says "the IETF can halt pervasive monitoring."

You don't quite say either of those above, but neither do you
acknowledge that the draft in question, and all the sensible discussion
(which is far from all the discussion;-) around that fully acknowledges
that the technical things that can and should be done are only part
of the story.

> The technical response must be coordinated with a political response, or
> else the perpetrators will find political means to route around the
> technical measures.

I disagree with "must be coordinated" for various reasons.

Given the time it takes for us to do our part, which is measured
in years before we get good deployment, imposing a requirement
to start with coordination would mean doing nothing ever.

Secondly, with whom would we coordinate? Again, trying to impose
a requirement for coordination with a non-existent Internet-wide
political entity is tantamount to doing nothing.

If some other folks outside the IETF are working on the same
issues that'll be good or bad, and for some such activities it'll
be useful for us to know about and consider them. And maybe it'll
be useful for others to know what we're up to, but we should
not wait.

> The political response shouldn't be organised within the IETF, but it does
> need to liaise with those responsible for doing that. 

"The" political response? You expect only one? Again, I don't
think we should hang around waiting - we should document the
consensus from Vancouver and then follow that through in our
normal work within working groups and elsewhere - considering
threats, including this one, as we develop protocols.

> Unfortunately I am
> not observing any movement by any of the other parties within our
> wonderful multi-stakeholder system that you would think would be
> notionally responsible for this. My fear is that they are opting to drink
> the technology Kool-Aid, to avoid grasping the political nettle. That is
> what should be concerning us right now.

Fully disagree. Its us should be grasping nettles and working
to improve the security and privacy properties of our protocols.

Regards,
S.