Re: [perpass] draft-farrell-perpass-attack architecture issue

"Fred Baker (fred)" <fred@cisco.com> Tue, 14 January 2014 21:45 UTC

Return-Path: <fred@cisco.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 A52B01AE245; Tue, 14 Jan 2014 13:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.039
X-Spam-Level:
X-Spam-Status: No, score=-115.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 88hM5Z4Nua3j; Tue, 14 Jan 2014 13:45:46 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 121491AE18B; Tue, 14 Jan 2014 13:45:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2669; q=dns/txt; s=iport; t=1389735933; x=1390945533; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Qztm/aaC677/65pQk8xped+U/y5kMvSpUwAwuWy4l+8=; b=CL1V1M+7BQz7L3D2ZibQeM6f3iYhc4qpODz/QrH6Hxw+7NpwWaS9yLtG W7shJstyqYL9GpUrhQD5UxdOtSsQ8JKgJXCUzhe50D9w7eEm3tzFLiNfi hTrRVNU8IfxIzbK+Mzuz4SrU4+OyykfoRZpmMxi/xjFNR7mLww+4556iB U=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aj8FAFiv1VKtJV2Y/2dsb2JhbABRCYMLOFa6bIEYFnSCJQEBAQMBZxIFCwIBCBIcARcyFw4CBA4FDgyHYggNw3gXjixbBxIBgxGBEwSQN4ExAoY0gTCQZYMtgWoHFyI
X-IronPort-AV: E=Sophos; i="4.95,659,1384300800"; d="asc'?scan'208"; a="297305395"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 14 Jan 2014 21:45:32 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0ELjWSp008760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jan 2014 21:45:32 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.86]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 14 Jan 2014 15:45:32 -0600
From: "Fred Baker (fred)" <fred@cisco.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Thread-Topic: draft-farrell-perpass-attack architecture issue
Thread-Index: AQHPEJW1zBILpAAtaEWpS3JElCG6BZqFJ00A
Date: Tue, 14 Jan 2014 21:45:31 +0000
Message-ID: <C19E19BF-B9A2-4EEB-8E77-DF0CAD548277@cisco.com>
References: <52D43E69.6090001@cs.tcd.ie>
In-Reply-To: <52D43E69.6090001@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.19.64.117]
Content-Type: multipart/signed; boundary="Apple-Mail=_BC463148-3AF9-4C49-A696-21C2858FD9E8"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Cc: perpass <perpass@ietf.org>, IETF-Discussion <ietf@ietf.org>
Subject: Re: [perpass] draft-farrell-perpass-attack architecture issue
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, 14 Jan 2014 21:45:48 -0000

On Jan 13, 2014, at 11:28 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

>  It means
>   that, if asked, there needs to be a good answer to the question "is
>   pervasive monitoring relevant to this work and if so how has it been
>   considered?"

Just a thought - that might be a good question to add to the shepherd's report.

In that case, I might suggest a minor change, however. We discuss "Pervasive monitoring" in a "big brother is watching" sense, and (at least in perpass) concern ourselves with data that could have been hidden had encryption or some other code used. I'll argue that, however dreadful Big Brother might be, location-based services can be a lot scarier.

http://online.wsj.com/news/articles/SB10001424052702303453004579290632128929194?mg=reno64-wsj&url=http%3A%2F%2Fonline.wsj.com%2Farticle%2FSB10001424052702303453004579290632128929194.html

Data point: a lot of these operate without specific knowledge of an individual, but can. For example, the article talks a lot about aggregating information and providing it without identifying information. However, it goes on to say that if someone logs into a service using, for example, a Facebook identifier, they can remain identified to the system as they wander around in it. The messages themselves contain no identifying information per se, but they contain information that can be correlated back to that login. And the login wasn't "data in flight", it was "creating state with a service at rest".

So the question in the shepherd's report should not be "tell me you thought about the EU Data Retention Initiative and whether your protocol's data identifies an individual". It should be "what personal, equipment, or session identifiers, encrypted or otherwise, are carried in your protocol? How might they be correlated with offline data or otherwise used to infer the identity or behavior of an individual?"