Re: [perpass] perpass: what next?

"Christian Huitema" <huitema@huitema.net> Wed, 29 April 2015 17:53 UTC

Return-Path: <huitema@huitema.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 BEA321ACDAF for <perpass@ietfa.amsl.com>; Wed, 29 Apr 2015 10:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 Zh2s2QclL9aI for <perpass@ietfa.amsl.com>; Wed, 29 Apr 2015 10:53:27 -0700 (PDT)
Received: from xsmtp12.mail2web.com (xsmtp12.mail2web.com [168.144.250.177]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEBE1ACDA8 for <perpass@ietf.org>; Wed, 29 Apr 2015 10:53:27 -0700 (PDT)
Received: from internal.xmail06.myhosting.com ([10.5.2.16] helo=xmail06.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <huitema@huitema.net>) id 1YnWAn-00075E-Ok for perpass@ietf.org; Wed, 29 Apr 2015 13:53:26 -0400
Received: (qmail 5206 invoked from network); 29 Apr 2015 17:53:23 -0000
Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[131.107.192.64]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <perpass@ietf.org>; 29 Apr 2015 17:53:23 -0000
From: Christian Huitema <huitema@huitema.net>
To: 'Stephen Farrell' <stephen.farrell@cs.tcd.ie>, 'perpass' <perpass@ietf.org>
References: <5530EEAB.5050601@cs.tcd.ie>
In-Reply-To: <5530EEAB.5050601@cs.tcd.ie>
Date: Wed, 29 Apr 2015 10:53:22 -0700
Message-ID: <008901d082a5$6372ff80$2a58fe80$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQJyRSr0dbs+AVu97VN1H/RMwXFCwpwgvjpA
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/perpass/Tgd_Xdcqsmg54s_VKHrKIl-FRqk>
Subject: Re: [perpass] perpass: what next?
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, 29 Apr 2015 17:53:28 -0000


> -----Original Message-----
On Friday, April 17, 2015, at 4:30 AM, Stephen Farrell wrote:
> ...
> Please discuss those here and/or send 'em to the IESG or to some
> random AD or to me. But discussing 'em on this list is way better,
> and of course even betterer is to write an I-D (and please do point
> again at ones you've written, just to refresh folks' minds).

OK Stephen, since you asked...

In general, I think of privacy mitigation in three steps. First, we have to
deploy encryption, and make sure that it actually works. We have lots of
activity on that. 

Second, we have to consider all the metadata that is not covered by
encryption, such as header elements or management protocols. We should apply
data minimization to mitigate that. We have some activity starting therewith
the DHCP anonymity profile in DHC and the data minimization work in DNSOP.
We need more of that, there are plenty protocols that leaks unencrypted
information, we have to scrub them.

Finally, we have to look at the "end-to-end" issues, such as all the
tracking that is taking place by means of cookies, cached files, browser
fingerprinting or e-mail analysis. I understand that the latter issue is a
bit controversial. The "pervasive monitoring" work concentrates on a threat
actor that can passively monitor a bunch of links, typically a state actor
with very big budgets. But protecting against this passive monitoring is not
sufficient.

Suppose that an advertising system collects enough data to understand the
type of chocolate that consumers prefer, their age, or the time they drive
their car. Suppose that this advertising company receives a visit of the
"men in black." They ask a simple question: please run this filter for us,
we really need to identify the "youth morning driver chocolate liberation
front." For the company, that is very much an "offer they cannot refuse."
For the men in black, that's way more effective than having to install a
bunch of taps everywhere and run a lot of data collection. And it doesn't
matter that all the traffic from the members of the liberation front was
encrypted...

-- Christian Huitema