[perpass] Getting started...

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 16 August 2013 16:42 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1EC2B11E8193 for <perpass@ietfa.amsl.com>; Fri, 16 Aug 2013 09:42:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id jeQ+x8PwVGWL for <perpass@ietfa.amsl.com>; Fri, 16 Aug 2013 09:42:46 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie []) by ietfa.amsl.com (Postfix) with ESMTP id DC5D611E8169 for <perpass@ietf.org>; Fri, 16 Aug 2013 09:42:45 -0700 (PDT)
Received: from localhost (localhost []) by mercury.scss.tcd.ie (Postfix) with ESMTP id A53EEBE59 for <perpass@ietf.org>; Fri, 16 Aug 2013 17:42:44 +0100 (IST)
Received: from mercury.scss.tcd.ie ([]) by localhost (mercury.scss.tcd.ie []) (amavisd-new, port 10024) with ESMTP id 0hdPuLwp68sl for <perpass@ietf.org>; Fri, 16 Aug 2013 17:42:44 +0100 (IST)
Received: from [] (stephen-think.dsg.cs.tcd.ie []) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7D551BE58 for <perpass@ietf.org>; Fri, 16 Aug 2013 17:42:44 +0100 (IST)
Message-ID: <520E5684.1090005@cs.tcd.ie>
Date: Fri, 16 Aug 2013 17:42:44 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: perpass@ietf.org
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [perpass] Getting started...
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <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, 16 Aug 2013 16:42:51 -0000

Hi all,

We've enough folks subscribed now (50ish) to kick off.

For those who weren't in Berlin, here's a bit of context. We had a
(hastily arranged:-) meeting after the tech plenary with about 30 or
so folks including Jacob and Linus from the Tor project.  Topics
ranged from that day's announcements from the Guardian newspaper to
issues the Tor project have faced with fingerprinting, and that lead
to a good discussion about how the current threat models we use in the
IETF (whether more or less formally) don't usually take into account
the potential for very widespread passive (or active) monitoring of
nodes using IETF protocols.  That was followed up in the bar in
various ways (please chime in if you remember bits of that or the
earlier chat I've missed out on:-) and we figured that setting up
this list would be a good starting point for us to try see what work
related to this topic might make sense in the IETF.

You should have seen the scope Sean and I figured might work for this
list [1] so let's try to keep to that, but its not a strict charter
or anything so don't be too constrained by it for now.  As this is an
IETF list, normal rules (IPR and netiquette) apply, if you're not
sure if something is appropriate for this list, feel free to ask Sean
or I offlist, but our hope is to try make progress on some or all of
the following:

- experiences with IETF protocols and how they allow for
  fingerprinting and monitoring, esp. in unexpected ways
- things we might practically do about that in the IETF, ideally in
  terms of concrete ideas for protocol or operational changes, and even
  more ideally with protocols that have active working groups who're
  interested in taking on such work
- ideas for new work that'd make our protocols more robust in the
  face of such pervasive monitoring
- descriptions of new threat models that might help people doing
  protocol work in the IETF
- how to get to a "privacy by default" situation as Randy called
- whatever else fits the scope:-)

The only thing to add to that for now is that since the kinds of
monitoring we're considering can be done at many layers, we should
not only be considering the web, or application layer or just
security protocols, but the full suite of protocols and areas in
which the IETF works.

And as usual, since its an IETF list, people need to grab a topic
and organise themselves to do the work or it probably won't happen.
But Sean and I are both supportive of this and willing to help
make sensible stuff happen if we can.

So over to you, what should we be doing?

Sean & Stephen.

[1] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg11780.html